在我們實作 Specification by Example（以下簡稱 SBE）的過程中，最常被問到的問題之一是：「我們要從哪裡找到具代表性的範例？」很多團隊一開始很自然地會聚焦在「欄位驗證」或「邏輯邊界」，例如價格是否為正數、年齡是否落在 18 到 65 之間……這些確實重要，但往往會讓討論流於片段與技術細節，失去了對整體「行為」的掌握。
這時，一個來自需求建模與測試分析領域的經典技巧就派上用場了：Use Case Testing（使用案例測試，UCT）。
它的出發點不是「驗證一個欄位或條件」，而是從使用者操作流程的角度出發，聚焦於「誰、做了什麼事、然後系統該如何回應」。這樣的觀點與 SBE 的精神非常貼近，尤其適合在設計複雜互動流程、權限邏輯、業務作業步驟時提供有力的支持。
Use Case Testing（使用案例測試）是一種基於使用情境（Use Case）來設計測試案例的技術，它的核心關鍵不在於技術細節，而在於行為流程的完整性。它通常從系統的 Use Case 描述文件、流程圖、業務場景腳本等素材中擷取出各種可能路徑，並對「主流程」、「替代流程」、「例外流程」分別設計對應的測試。
舉個簡單的例子：
以「ATM 提款」為 Use Case：
主流程：使用者插卡 → 輸入密碼 → 輸入金額 → 領款成功
替代流程：密碼錯誤三次 → 卡片被鎖
例外流程：ATM 沒鈔票 → 顯示錯誤訊息
Use Case Testing 會針對這些流程撰寫測試案例，以確保所有使用情境都能被妥善處理。
以下是建議步驟流程，適用於測試分析階段或範例設計工作坊。
Step 1：確認主使用案例（Primary Scenario）
Step 2：列出替代流程（Alternative Flows）
Step 3：拆解流程成步驟與條件點
Step 4：針對每條流程路徑產生測試案例
注意 1：流程不是欄位驗證，範例應該呈現「狀態轉移」或「決策分歧」
在 Use Case Testing 中，我們關注的是「行為結果的差異」，而非單一欄位的輸入是否合法。許多團隊誤把範例寫成表單驗證，失去流程意圖。
a. 錯誤範例：
測試密碼長度不足 → 顯示錯誤
這只是欄位驗證，應交由 Boundary Testing 處理。
b. 正確範例（基於流程）：
範例：使用者登入失敗三次後帳號鎖定
Given 使用者在登入頁面
When 輸入錯誤密碼三次
Then 顯示「帳號已鎖定」
And 禁止再次登入
注意 2：替代流程需命名清楚，避免模糊
很多替代流程像是「重新嘗試」、「取消流程」等，若沒具體描述情境，容易造成測試與開發雙方理解不一致。
範例：付款失敗後重新付款成功
Given 使用者已選擇商品並前往付款
When 第一次付款失敗
And 使用者點選「重新付款」
And 第二次付款成功
Then 訂單狀態為「已完成」
這樣能幫助團隊明確理解：流程允許回復、不會中斷。
注意 3：例外流程不等於 Bug，它是業務允許的行為分支
例外流程常被誤認為「出錯就跳錯誤訊息」，但 Use Case 的例外流程，是指「在預期外輸入下系統仍可正常回應」。
範例（處理例外）：
範例：使用者取消訂單
Given 訂單尚未付款
When 使用者點選「取消訂單」
Then 訂單狀態為「已取消」
And 系統不會產生付款請求
這是一條可接受的例外分支，不是錯誤，而是業務流程的一部分。
注意 4：要釐清角色差異，避免誤把行為混為一談
Use Case 通常會涉及不同角色（例如：一般使用者 vs 管理員），而行為的允許與否也會因角色而異。
範例：管理員取消已付款訂單
Given 訂單狀態為「已付款」
And 使用者身分為「管理員」
When 點選「取消訂單」
Then 訂單狀態為「已取消」
And 系統產生退款申請
若相同流程換成一般使用者，就可能禁止取消。這些邏輯必須透過角色區分清楚呈現。
注意 5：流程步驟過長時，需切分為多個小 Use Case
若單一範例描述過長的流程（例如：註冊→瀏覽→加購物車→付款→開發票→退貨），不僅難以維護，也模糊了驗證目標。
建議做法：
將整個購物流程切分為三個 Use Case：
下單流程（瀏覽＋選購＋付款）
發票流程（依付款成立啟動）
退貨流程（僅針對已出貨狀態）
每個 Use Case 對應的範例才不會彼此干擾，利於驗收與測試維護。
注意 6：不要只寫主流程的成功案例，要有完整分支覆蓋策略
很多團隊只寫 happy path（主流程成功執行），卻忽略：
輸入錯誤的替代流程
中途取消或返回的流程
系統異常或資料缺失的處理路徑
範例對照（主流程 vs 替代流程）：
主流程：
範例：使用者下單成功
Given 商品庫存充足
When 使用者完成付款
Then 顯示「下單成功」
And 庫存扣除
替代流程：
範例：使用者付款成功但商品已售完
Given 商品在付款前已被搶購一空
When 使用者完成付款
Then 顯示「庫存不足」
And 啟動退款流程
完整的 Use Case Testing 會針對每一種分支都提供具體範例，不只驗證系統正確，更展現了需求的邊界與責任。
這是一個週三下午，台灣高鐵的數位服務開發團隊，聚在一起討論新專案：「讓學校可以線上申請校外教學優惠票。」
PO 小美打開簡報：「我們有三種情境，條件不同、折扣也不同，我來簡單講一下。」
工程師阿明聽完後點點頭：「那應該就條件判斷嘛，看是不是學校、是不是 25 人、是不是指定車次……」
但 QA 小貞卻搖了搖頭：「等等，這裡不只是條件組合。這是一組互斥、但條件重疊的使用情境。如果我們不先釐清每一個情境的流程，我們根本不知道該怎麼測。」
小美問：「那怎麼辦？這些流程文件還沒生出來，需求就要排進去了。」
小貞說：「那我們就從 Use Case 開始。我們不針對欄位條件討論，我們從『使用者怎麼做』開始，把流程釐清，再設計範例。」
Step 1：定義主流程 Use Case
小貞在白板寫下第一個 Use Case 標題：
【Use Case：申請團體票】
Step 2：列出替代流程與例外情境
「剛剛大家以為是簡單的 if-else 判斷，但事實上，這些流程中間有很多會分叉的點，」小貞說。
她一一列出可能的分支流程：
替代流程：
3A：人數未達 11 人 → 不允許申請
3B：人數達 25 人以上、非學校 → 顯示 25人優惠選項
3C：為學校團體、搭指定車次 → 顯示校外教學優惠折扣方案
3D：學校團體但搭非指定車次 → 不提供折扣，僅一般團體票
5A：折扣方案有多個時，需選擇適用方案（待釐清）
例外流程：
E1：車次未開放團體票申請 → 顯示「無法申請此車次」
E2：成員資料不完整 → 提示補件
E3：混齡團體 → 折扣計算邏輯模糊（需 PO 回覆）
E4：老師人數是否計入總人數？（待釐清）
Step 3：針對每條流程設計 Specification by Example 範例
「我們現在針對這些流程撰寫範例，重點不是填寫所有欄位，而是讓每一個流程分支都被具體例子覆蓋到。」小貞提醒大家。
以下是他們一起列出的範例：
範例 1：符合校外教學條件的小學團體
範例：30位小學生、學校團體、搭指定車次、平日
Given 團體人數為 30 人
And 成員皆為小學生
And 團體屬性為「學校」
And 搭乘車次為「指定車次」
And 搭乘日期為平日
When 提交申請
Then 系統提供校外教學優惠
And 每位票價為原價的 4 折
範例 2：25人以上、非學校團體、假日搭乘
範例：30人企業團體搭指定車次
Given 團體人數為 30 人
And 團體屬性為「非學校」
And 搭乘日期為假日
And 車次為指定車次
When 提交申請
Then 系統提供 8 折團體票
範例 3：學校團體但非指定車次
範例：12位高中生、搭非指定車次
Given 團體人數為 12 人
And 團體屬性為「學校」
And 學歷為高中
And 搭乘非指定車次
When 提交申請
Then 系統僅提供一般團體票
And 無折扣
待釐清範例 A：混齡團體（小學＋高中）
範例：小學與高中生混合校外教學
Given 團體人數為 15 人
And 學歷組成包含小學與高中
And 團體屬性為「學校」
And 搭乘指定車次
When 提交申請
Then 系統是否可分開折扣？（待確認）
待釐清範例 B：10位學生＋1位老師
範例：老師是否計入人數？
Given 學生人數為 10 人
And 隨行教師為 1 人
When 提交申請
Then 系統是否接受滿 11 人？（待確認）
Step 4：建立 Use Case 測試覆蓋地圖
最後，小貞把這些範例整合到一份「流程覆蓋圖」中：
當天會議結束時，小美感慨地說：
「我們原本只想判斷是不是學校、有沒有達人數，但現在我才發現，不是條件的問題，而是流程設計的問題。」
阿明也點頭說：
「Use Case Testing 真的把我們從欄位檢查拉回整個體驗流程，這才是對使用者有價值的驗證方式。」
小貞補上一句話作為總結：
「每一個使用案例，不只是測試的一條流程，它其實是系統設計決策的一面鏡子。我們不是在找例子而已，我們是在發現需求的空隙。」
iThome鐵人賽
看影片追技術